Volume 1

Issue 2

June 2004

Tools and Technology Implementation: Issues with Granularity Steve Manning, The Rockley Group, Inc. Making the transition from document management to content management means that you have to look within documents for the structure of your content management system. How big should the pieces of content in your system be? There are many factors that affect the physical granularity of the content you manage. There are many factors that affect the granularity of information you create, manage, and maintain. Factors include: The type of reuse you are supporting The nature of your authoring life cycle The technology of individual content management systems The data format of the content management system-XML or not Types of reuse We should begin with a discussion of types of reuse, but a limited discussion. When we talk about reuse, we usually talk about things like opportunistic and systematic. But, these are really modes of reuse. The types of reuse that affect granularity are filtered reuse and modular (or building-block) reuse. In filtered reuse, authors provide all variants for a specific chunk of information in a single block of content, e.g., they include all the content to support all levels of users, or all outputs. The variations are identified by conditional tags or attributes of some type. When the block is converted into output formats, variations that are not needed for a specific output (e.g., the user guide) can be filtered out through stylesheets. In modular reuse, content is written in separate physical blocks (building blocks) of content. The blocks are then combined (either by the author or automatically by the system) to create the output. Of course, these two types of reuse can be-and frequently are-combined to provide the necessary functionality for authoring and presentation. However, filtered reuse has fewer implications for implementation than modular reuse; content can be managed in large chunks, because it is filtered by the publication engine. Granularity and modular authoring In addition to reuse types, the granularity that you implement in your content management system may also depend on the authoring life cycle of your content. In a collaborative authoring situation, where authors provide fragments of content, you may want to maintain those fragments as contiguous pieces in the content management system. This allows contributing authors to check out and check in only the content elements they need to work on. They do not need to navigate through entire chapters to find the section or sub-section they need to author. Providing contributing authors only the pieces they need helps them to focus on the individual task at hand. They do not need to see and be distracted by the rest of the document. Where individual elements of content from the authoring chunks will be used in multiple places (building block style), it may be necessary to break the content into small pieces for storage and reuse, but reassemble the pieces for authors so they can edit and manipulate content elements in their entirety. The effect of technology It would be nice to say that all content management systems are created equally, and thus be equally capable of managing individual elements of content, but it is neither true, nor is it reasonable to expect it to be true. Many content management systems began life as document management systems, and were focused on the administration and management of document files. However, content management means having the ability to manage the individual chunks of content that have traditionally been combined in individual files to make documents. In making the transition to content management, these document management systems opened up access to the elements of the document. In contrast, there are also content management systems on the market that were built with the express purpose of manipulating the content elements that make up information products. Note the use here of "information products" and not "documents." The term "documents" implies paper. These content management systems grew in parallel with the Web and have therefore been designed to support both paper and online content. Older systems tend not to support fine levels of granularity. They usually require that documents be "burst" or broken into individual pieces as they are checked into the repository. Frequently, this mechanism has been "bolted" onto an existing system to add the functionality to manage elements. This bursting mechanism must usually be configured into the system as a custom extension. The drawback to this is that the system becomes "hardwired", and changes are expensive to make. Also, if you want a fine level of granularity, where many elements are broken out and managed individually, the costs of customizing the system may become prohibitive. Newer systems, especially those created specifically for managing fragments of content, have a significant advantage. Many of them manage individual elements as part of their base functionality and don't require an add-on. These systems may or may not actually require you to burst the content. Many of them are built to automatically burst the content, giving you access to all individual elements. The ability of a content management system to manage and manipulate elements will be a key factor in the granularity of a system. Systems can manage elements to different degrees, and not all systems will be able to support your level of granularity. XML There are very few content management systems that do not support XML, which is a good thing. The very nature of XML, with clear boundaries of elements and a general orientation towards databases, makes it an excellent data format for managing content. Therefore, XML-based content management systems offer the greatest flexibility for managing content at a very granular level. Like the basic ability to manage elements, the way in which XML support has been built into a system can affect the level of granularity. Some systems have XML capability "bolted on", where XML content is transformed into something else for storage. Native XML systems, however, were created specifically to manage XML content. Summary The level of granularity that is right for your content management system depends on a number of factors (in addition to information architecture), including types of reuse, collaborative or local authoring, and the technology you are using to support your content management.